Skip to content

feat(rust/sedona-raster-zarr): derive Zarr transform from spatial:bbox#975

Merged
paleolimbot merged 2 commits into
apache:mainfrom
james-willis:jw/zarr-bbox-transform
Jun 26, 2026
Merged

feat(rust/sedona-raster-zarr): derive Zarr transform from spatial:bbox#975
paleolimbot merged 2 commits into
apache:mainfrom
james-willis:jw/zarr-bbox-transform

Conversation

@james-willis

Copy link
Copy Markdown
Contributor

No description provided.

@github-actions github-actions Bot requested a review from paleolimbot June 17, 2026 23:28
@james-willis james-willis force-pushed the jw/zarr-bbox-transform branch 2 times, most recently from eb8071d to 068099c Compare June 18, 2026 21:59
When a group has no explicit spatial:transform, derive a GDAL-order geotransform
from spatial:bbox plus the array's own spatial shape (+ optional
spatial:registration, default "pixel").

The derivation lives in the loader's transform-fallback chain, ahead of the
coordinate-array path, so it uses the array shape already in hand rather than a
separate, drift-prone spatial:shape attribute (bbox alone is sufficient).
geozarr.rs stays a pure attribute decoder that surfaces the bbox and
registration; the loader applies them.

A malformed or degenerate/inverted bbox is non-fatal: it warns and falls through
to the coordinate arrays (then identity), matching how a bad coordinate array is
handled. When the bbox path derives a transform and the group declares no CRS, a
geographic CRS is inferred from the spatial dim names, mirroring the
coordinate-array path.
@james-willis james-willis force-pushed the jw/zarr-bbox-transform branch from 068099c to 35ac003 Compare June 18, 2026 22:13
@james-willis james-willis marked this pull request as ready for review June 22, 2026 21:46

@paleolimbot paleolimbot left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few things maybe worth taking care of here but in general looks good...thank you!

I am not sure if we're keeping a list of real-life public zarrs that we can support, but it might be a good idea to at least keep them in the doc header for open_and_validate if we don't have an analogue in sedona-testing.

Comment thread rust/sedona-raster-zarr/src/geozarr.rs Outdated
Comment thread rust/sedona-raster-zarr/src/loader.rs
@james-willis

Copy link
Copy Markdown
Contributor Author

it might be a good idea to at least keep them in the doc header for open_and_validate if we don't have an analogue in sedona-testing.

They're like Pokemon, im going to catch them all 😄

Move the bbox-to-geotransform derivation out of sedona-raster-zarr into
AffineMatrix::from_bbox_and_spatial_shape (with a to_gdal_geotransform helper),
so it is reusable beyond Zarr. Add a rasterio from_bounds cross-check test. In
the Zarr loader, split the transform-resolution block into resolve_group_transform
/ transform_from_bbox / transform_from_coordinate_arrays.

@paleolimbot paleolimbot left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@paleolimbot paleolimbot merged commit 1a9a69a into apache:main Jun 26, 2026
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants